AWS Bedrock Knowledge Base

AWS Bedrock: Strands vs AgentCore - A Clear Comparison

The Big Picture: What They Actually Are

Strands (AWS Strands Agents)

Strands is a framework/SDK — a toolkit for writing AI agents.

Key Characteristics: - Open-source and code-first: Define agent logic, planning loops, tool integration, reasoning, error handling, and memory patterns explicitly in code - Primitives for agent building: Tool use, multi-model support (Bedrock, OpenAI, Anthropic, local models), and agent orchestration - Maximum flexibility: Custom tools, multi-agent workflows, deployment anywhere (Lambda, EC2, EKS, on-prem, edge) - Not a hosted platform: Requires a runtime or hosting environment for production deployment

In simple terms: Strands = the engine and controls for defining what your agent does.

AgentCore (Amazon Bedrock AgentCore)

AgentCore is a production platform for running agents at enterprise scale.

Key Characteristics: - NOT a framework: It's a deployment and operations platform, not for writing agent logic - Framework agnostic: Supports any agent framework (Strands, LangGraph, CrewAI, LangChain, etc.) - Enterprise-grade infrastructure: Secure serverless runtime, session isolation, persistent memory, IAM integration, logging/observability, policy enforcement - Operations focused: Takes dev-written agents and makes them production-ready with security, scaling, auditing, and compliance

In simple terms: AgentCore = the production platform where your agent runs.

Head-to-Head Comparison

Aspect Strands AgentCore
Primary Role Framework/SDK to build agent logic Production platform to run agents
Managed Service? No (you run it where you want) Yes (AWS handles infra & scaling)
Enterprise Features Limited (dev tooling) Full enterprise features (security, monitoring, identity)
Flexibility Very high — multi-model & multi-env High, but focused on scalable deployment
Ease of Use More coding upfront Less custom code — more managed deployment
Model Agnostic? Yes (supports non-AWS too) Yes (runs any agent framework/model)
Focus Defining what the agent does Running how it does it reliably at scale

How They Fit Together

You can — and usually should — use them together:

  1. Build your agent logic with Strands (reasoning, tools, memory, workflows)
  2. Deploy to AgentCore for secure, scalable production execution

Strands integrates with AgentCore seamlessly: AgentCore expects a specific handler structure, and Strands automatically wraps your logic to fit that contract, eliminating boilerplate and integration headaches.

The Real Difference: Strands is where you define your agent (the brain and behavior). AgentCore is where you run and operate it in a robust, secure, scalable enterprise environment.

Deploying Strands Agents: With vs Without AgentCore

The Agent Itself: What Does NOT Change

Regardless of deployment target, your Strands agent logic remains identical: - Reasoning loop - Tool calling logic - Prompting strategy - Multi-step planning - Memory abstractions (conceptually)

Key principle: Strands defines behavior. Deployment defines operation.

Deploying WITHOUT AgentCore

What you get: - Full control over runtime (EC2, EKS, Lambda, on-prem, local) - No AWS opinionated constraints - Easier experimentation and debugging - Lower cost at small scale

What you must handle yourself: - ❌ Session isolation - ❌ Persistent memory storage - ❌ Authentication & identity - ❌ Rate limiting & abuse protection - ❌ Observability (logs, traces, metrics) - ❌ Scaling under concurrency - ❌ Compliance & auditability

You are effectively building your own AgentCore.

Good for: - Prototypes - Internal tools - Low-risk automation - Research - Startups valuing speed over guardrails

Deploying ON AgentCore

What changes: Not the agent logic — the runtime contract changes. AgentCore wraps your Strands agent in a managed execution environment.

What AgentCore provides: - ✅ Managed runtime (no server management) - ✅ Session-scoped execution (no cross-user leakage) - ✅ Built-in identity & IAM integration - ✅ Persistent memory services - ✅ Enterprise observability - ✅ Automatic scaling - ✅ Security boundaries and policy enforcement - ✅ Compliance-friendly architecture

Your agent becomes a governed service, not just code.

The Real Difference in One Sentence

Without AgentCore: Your Strands agent is a program.

With AgentCore: Your Strands agent is a production service.

Practical Mental Model

Think of it like traditional application development:

One is code. The other is operational maturity.

When to Use AgentCore

Use AgentCore if any of the following are true: - Multiple users - External access - Regulated data - Long-running conversations - Audit requirements - Production SLAs - You don't want to reinvent infrastructure plumbing

If none apply, deploying outside AgentCore is reasonable — and often smarter early on.

Where Bedrock Fits In

What Bedrock Actually Is

Amazon Bedrock = managed access to foundation models.

That's it.

Bedrock does NOT: - Manage agent lifecycles - Run workflows - Handle sessions - Orchestrate tools - Deploy agents

Old-school analogy: Bedrock = the database or API you depend on, not your application.

The Three-Layer Stack

Bedrock    → "Here's the model output"
Strands    → "Here's how the agent thinks, plans, and uses tools"
AgentCore  → "Here's how this agent runs safely for many users at scale"

Each layer is cleanly separated.

Bedrock + Strands (WITHOUT AgentCore)

Your app
  └── Strands agent
        └── Bedrock model call

What's happening: - Strands uses Bedrock as its LLM backend - You manage: runtime, sessions, auth, scaling, logging, memory - Bedrock just answers model requests

Important: Bedrock doesn't care whether you're using Strands, LangChain, raw SDK calls, or AgentCore. It only sees inference requests.

Common for: - Prototypes - Internal tools - Single-tenant systems - Early-stage products

Bedrock + Strands + AgentCore (Full AWS Stack)

Client / User
  └── AgentCore (runtime, sessions, identity)
        └── Strands agent (logic & tools)
              └── Bedrock (LLM inference)

This is the intended enterprise stack with clean separation of concerns.

Does AgentCore REQUIRE Bedrock?

No. AgentCore can run agents using any model, including non-Bedrock models and external APIs.

However, in practice: - If you're in AWS, Bedrock provides IAM, quotas, logging, compliance - AgentCore integrates cleanly with it - Procurement and security teams are happier

AgentCore doesn't require Bedrock, but AWS clearly expects you to pair them.

What Changes If You Don't Use Bedrock?

If you skip Bedrock, you manage: - API keys - Rate limits - Vendor risk - Compliance posture

Fine for startups and labs. A red flag in regulated environments.

Bedrock exists mainly to keep enterprises comfortable.

The One-Sentence Mental Model

Bedrock is the brain supply. Strands is the brain wiring. AgentCore is the body and nervous system.

Take one away, and you inherit the responsibility.

Common Mistakes

Teams often ask: "Should we use Bedrock Agents or Strands or AgentCore?"

That's the wrong question.

The correct sequence is: 1. Which models do we trust? → Bedrock or not 2. How do we want to write agent logic? → Strands or another framework 3. Who runs this in production? → AgentCore or us

Clear layers. No confusion.

Final Summary

Strands lets you build agents properly. AgentCore lets you run them responsibly.

Skipping AgentCore doesn't make your agent weaker — it makes you responsible for everything AWS would've handled. Some teams are ready for that. Most aren't, even if they think they are.

Decision Framework

Use Strands Alone When:

Add AgentCore When:

Use Bedrock When: